これまでの連載で、SIPの「思想」と「インフラ（トランスポートやサーバー群）」について解説してきました。
第3回となる今回は、いよいよ通信の主役である「SIPメッセージ（パケットの中身）」と、それらが織りなす「シーケンス（通信の流れ）」にメスを入れます。

レガシーな電話機における「受話器を上げる（オフフック）」「プルルルという呼び出し音（リングバック）」「電話を切る（切断）」といった物理的な動作は、IPネットワーク上でどのようにデジタルなSIPメッセージへと変換されているのでしょうか？
本記事では、独自実装のシーケンス図を用いながら、数々のメソッド（INVITE, PRACK, CANCEL等）や複雑なヘッダ群（Record-Route, Contact等）、さらにはプレゼンス機能まで、エンジニアが実務で直面する疑問を徹底的に解き明かします。

1. 【図解】一目でわかる！SIPの基本シーケンスと電話用語の対比

文字だけでSIPのやり取りを理解するのは困難です。まずは、「Aさん（発信者）がBさん（着信者）に電話をかけ、通話し、切断する」という最も基本的な流れを、プロキシサーバーを経由するシーケンス図で見てみましょう。

アナログな電話用語との関係性を整理しましょう。

• オフフック（受話器を上げる）： 発信者が番号を入力して発信ボタンを押した瞬間、SIPではINVITEメソッドが生成されます。
• リングバック（呼び出し音）： 着信側の端末が鳴動を始めると、ネットワークを通じて180 Ringingが返ってきます。発信側の端末はこれを受け取って、スピーカーから「プルルル」というリングバックトーン（疑似音）を再生します。
• 切断： どちらかが通話を終了すると、BYEメソッドが送信され、セッションが破棄されます。

2. SIPメソッド（リクエスト）と高度な制御

基本的な INVITE, ACK, BYE 以外にも、SIPには通信を確実かつ柔軟に行うための重要なメソッドが存在します。特に実務で頻出するものを解説します。

CANCEL（キャンセル）

発信者が「あ、間違えた」と、相手が電話に出る前（200 OKが返ってくる前）に発信を取りやめるためのメソッドです。すでに通話が成立した後に切断する場合はBYEを使いますが、通話成立前はCANCELを使わなければなりません。

PRACK（Provisional Response Acknowledgement）

第2回で「SIPはUDPを使うことがある」と説明しました。UDPはパケットが途中で消える可能性があります。
200 OK という最終応答には ACK という確認応答がありますが、180 Ringing などの「暫定応答（1xx）」には本来確認応答がありません。
もし 180 Ringing がネットワークで消失したら？ 発信者は「相手の電話が鳴っているかどうかわからない」状態に陥ります。これを防ぐため、「暫定応答（1xx）を確実に受け取ったこと」を相手に伝えるための確認メソッドが PRACK です。（RFC 3262による拡張機能です）。

3. レスポンスコード：状態を示す3桁の数字

SIPの応答は、HTTPと同じように3桁の数字（ステータスコード）で表されます。

• 1xx (暫定応答 / Provisional): 処理中であることを示します。
  • 100 Trying: 「今、一生懸命ルーティング先を探して処理していますよ」というプロキシからの合図。
  • 180 Ringing: 相手の端末まで到達し、ベルを鳴らしている状態。
• 2xx (成功 / Successful): 要求が正常に処理されたこと。
  • 200 OK: 相手が電話に出た、または要求（BYEなど）が受理された。
• 4xx (クライアントエラー): 発信者側の問題。
  • 401 Unauthorized: 認証が必要。REGISTER（登録）時などに、サーバーが「パスワードによるダイジェスト認証を求めている」状態です。

4. 複雑怪奇な「SIPヘッダ」の解剖

SIPメッセージは、メタデータ（宛先や経路情報）を記した「ヘッダ」と、実際のメディア情報を記した「ボディ（SDP）」に分かれます。ここでは、ご質問にあった重要なヘッダ群の役割を整理します。

5. 応用機能１：プレゼンス機能と関連メソッド・ヘッダ

SIPは通話だけでなく、チャットツールなどで見られる「在席中」「会議中」「オフライン」といったプレゼンス（状態）情報を共有する機能も標準で備えています。

ここで登場するのが、SUBSCRIBE と NOTIFY という2つのメソッドです。

• SUBSCRIBE（購読）： 「Aさんの状態が変わったら教えて！」と、プレゼンスサーバーにお願い（登録）するメソッドです。
• NOTIFY（通知）： Aさんが「会議中」ステータスに変更した瞬間、サーバーから登録者へ「状態が変わりましたよ」と通知をプッシュするメソッドです。

このやり取りには、専用のヘッダが使われます。

• Event ヘッダ： 何のイベントを監視するか指定します。（例：Event: presence）
• Subscription-State ヘッダ： 監視状態が現在有効（active）か、終了した（terminated）かを示します。

IoTデバイスの監視カメラが「動体検知」した瞬間に管理者に通知を送る仕組みなども、このプレゼンスアーキテクチャの応用です。

6. 応用機能２：コーラープリファレンス（Caller Preferences）

通常、着信をどう処理するか（デスクの電話を鳴らすか、留守電に繋ぐか）は、「着信側（受ける側）」が設定します。
しかし、SIPの拡張機能であるコーラープリファレンスを使うと、「発信者側（かける側）」がネットワークに対してルーティングの希望（プリファレンス）を指示することができます。

これにより、コンタクトセンターの優先ルーティングなど、極めて高度な呼制御が可能になります。

第3回のまとめと次回予告

今回は、SIPの骨格となるメッセージ群とシーケンス、そしてヘッダの役割について解説しました。

• INVITEからBYEまでの流れは、レガシー電話のオフフック〜切断を美しくデジタル化したものである。
• PRACK（暫定応答の確認）やCANCELなど、通信を堅牢にするメソッドが存在する。
• Record-RouteやContactなど、多数のヘッダが協調してルーティングや認証を制御している。
• SUBSCRIBE / NOTIFYを用いたプレゼンス機能により、IoTやチャット連携の道が開かれている。

さて、ここまで「通話のお膳立て（シグナリング）」については完璧に理解できたはずです。しかし、肝心の「音声や映像のデータ」については、まだ一切触れていません。

いよいよ次回、最終回となる第4回「メディア制御（SDP/RTP）と堅牢なセキュリティの全貌」では、SIPが運ぶボディ部分であるSDPの各種フィールド（v, o, m, c 等）やOffer/Answerモデル、実際にメディアを運ぶRTP/RTCPの仕組み、そして改ざんやDoS攻撃からシステムを守るS/MIMEやSIPSなどのセキュリティ技術について徹底解説します。ご期待ください！